Various computer applications are used to create graphics, applications, animations, videos, and other electronic content. Many such applications provide a what-you-see-is-what-you-get (WYSIWYG) interface that allows the appearance of the electronic content being created to be specified on a graphical canvas area. For example, such an interface may allow the size, shape, and other display attributes of a button to be changed by a content creator manipulating a graphical representation of the button. Many aspects of electronic content cannot be fully specified through interactions with a WYSIWYG canvas. Property-selection panels are used to supplement the canvas interfaces of such editors. For example, a color selection panel may pop-up to allow a creator to specify the background color of a displayed button. Other aspects of electronic content must be specified in manually-entered software code. For example, the function and/or text of a button may be specified in software code.
The creation of electronic content can involve persons with different skills and experiences. Many of those involved in the creation of electronic content cannot or will not write or read software code, or otherwise dislike having to work with software code. Such persons are collectively referred to herein as “designers,” while persons who interpret, read, write, create, and/or edit code are collectively referred to as “developers.”
Designers commonly use WYSIWYG interfaces to design the appearance of electronic content. Some WYSIWYG interfaces facilitate the creation of graphical and some interactive aspects of electronic content without requiring knowledge or use of software code. However, the use of some electronic content features, functions, and customizations requires that developers add software code. To create such electronic content, designers often collaborate with one or more other people who add the software coding to the electronic content. Different electronic content creation applications can be designed to edit the same piece of electronic content yet target the different types of content creators, i.e., designers and developers. An electronic content creation application that targets designers can provide a limited interface so that the designers are not encumbered with features that will not be used.
The use of separate electronic content applications that provide different interfaces can provide various benefits. However, they also provide a potential for incompatibility. An electronic content creation application that targets designers may, for example, understand only a subset of the possible elements that might be used in the electronic content. As a specific example, a creation application that targets designers may not provide functionality to display cascading-style-sheet (CSS) features, even though such features can be added to the electronic content being created by the developer. Such lack of capability may provide an advantage since CSS relates to program-like logical rules that are applied to define the appearance of objects. Avoiding CSS, and other software code-specific features, can simplify the creation application's interface and make it easier for designers to use. Moreover, it can be advantageous to limit or avoid interpreting developer-entered, arbitrary code with respect to a WYSIWYG interface. Programming languages designed for developer-coding are generally very complex and have many constructs that have no visual representation.
Because a creation application that targets designers may have limited capabilities, incompatibility issues may arise if it opens electronic content that contains features added by another, more capable creation application. Compatibility issues can occur if manual code is inserted in a collaborative project by a developer, for example, to add business logic, data connectivity, etc. Opening a project, a designer might find that it does not compile, does not quite work, or cannot be edited. Because of such incompatibilities, a common workflow involves a designer creating the visuals for a project, handing those visuals off to development, and then not expecting to change anything except by sending mockups or textual requests to the developer, who then integrates the changes. This can be inefficient and often sacrifices the integrity of the designer's vision and intentions.